These words of warning apply also to the macro worksheets generated by popular PC spreadsheet programs. Although it seems natural to declare a type "application/x-msexcel-macro" in order to receive spreadsheets that automatically recalculate themselves, some of the functions in the Excel macro language have the potential to inflict damage on other worksheets and files. These warnings even apply to such seemingly innocuous things as word processor style sheets and template files! Many high end word processors have a built-in macro processing ability. An example of the way in which word processing macros can be misused is the Microsoft Word "prank macro", which has the ability to spread, virus-like, from document to document.
I have heard of at least one individual who decided he'd only be using
the C-shell to download scripts written by himself and other trusted
parties. He screened all URLs by hand to make sure they didn't end
with a .csh extension before downloading them.
Unfortunately the file extension is not a reliable way to determine
what a URL contains. The type of a document is determined by the Web
(HTTP) server, not the browser, and a document of type application/x-csh
can just as easily have an extension of .txt or no
extension at all.
In short, beware of declaring an external viewer for any file that contains executable statements.
This security problem is addressed by scripting languages as Java and Safe Tcl in which dangerous functions can be disabled. There's even a prototype "Safe Perl" that can be used as a safer external viewer for perl programs.
To turn this warning off, select Preferences from Netscape's Options menu, choose "Images and Security", and uncheck the checkbox labeled "Warn before submitting forms insecurely."
Netscape servers and browsers do encryption using either a 40-bit secret key or a 128-bit secret key. Many people feel that using a 40-bit key is insecure because it's vulnerable to a "brute force" attack (trying each of the 2^40 possible keys until you find the one that decrypts the message). Using a 128-bit key eleiminates this problem because there are 2^128 instead of 2^40 possible keys. Unfortunately, most Netscape users have browsers that support only 40-bit secret keys. This is because of legal restrictions on the encryption software that can be exported from the United States (The Federal Government has recently modified this policy on following the well-publicized cracking of a Netscape message encrypted using a 40-bit key. Expect this situation to change).
In Netscape you can tell what kind of encryption is in use for a particular document by looking at the "document" information" screen accessible from the file menu. The little key in the lower left-hand corner of the Netscape window also indicates this information. A solid key with two teeth means 128-bit encryption, a solid key with one tooth means 40-bit encryption, and a broken key means no encryption. Even if your browser supports 128-bit encryption, it may use 40-bit encryption when talking to older Netscape servers or Netscape servers outside the U.S. and Canada.
The contents of queries in forms submitted using the GET request appear in the server log files because the query is submitted as part of the URL. However, when a query is submitted as a POST request (which is often the case when submitting a fill-out form), the data you submit doesn't get logged. If you are concerned about the contents of a keyword search appearing in a public log somewhere, check whether the search script uses the GET or POST method. The easiest technique is to try an innocuous query first. If the contents of the query appear in the URL of the retrieved document, then they probably appear in the remote server's logs too.
Server/browser combinations that use data encryption, such as Netsite/Netscape, encrypt the URL request. Furthermore the encrypted request, because it is submitted as a POST request, does not appear in the server logs.
JavaScript is a series of extensions to the HTML language understood only by Netscape Navigator versions 2.0 (and higher). It's an interpreted language designed for controlling the Netscape browser; it has the ability to open and close windows, manipulate form elements, adjust browser settings, and download and execute Java applets.
Although JavaScript has a similar syntax to Java, it is quite distinct in many ways.
Several failsafes are built into Java to prevent it from compromising the remote user's machine. When running as applets, Java scripts are restricted with respect to what they are allowed to do. They are not allowed to execute arbitrary system commands, to load system libraries, or to open up system device drivers such as disk drives. In addition, scripts are generally limited to reading and writing to files in a user-designated directory only (the HotJava browser allows you to set this directory, while Netscape disallows all file manipulation).
Applets are also limited in the network connections they can make: An applet is only allowed to make a network connection back to the server from which it was downloaded. This is important for reasons discussed below.
Finally, a fundamental limitation on Java applets is that they can read and write to the network, read and write to the local disk, but not both. This limitation was created to reduce the risk of an Applet spying on the user's private documents and transmitting the information back to the server.
Unfortunately in the short time since its release, a number of security holes have been found in Java caused by bugs in the implementation. Although most of the known bugs have been fixed in the current release, at least one serious security hole remains. You are advised to turn Java off (from the Netscape Security Preferences menu item) except when retrieving URLs from well-known and trusted hosts.
This bug is said to be present in version 2.0 of Netscape as well as the recent 2.01 "security enhancements" release. The authors have not stated whether the bug is limited to Unix versions of Netscape Navigator, or are present in the Windows and (beta release) Macintosh versions as well. More information on this bug can be found at:
http://www.cs.princeton.edu/~ddean/java
Applets are supposed to be able to talk only to the server that they originated from. However in early March 1996, Steve Gibbons ( sgibbo@amexdns.amex-trs.com) and Drew Dean (ddean@CS.Princeton.EDU) independently discovered holes in the implementation that allows Applets to make connections to any host on the Internet. This is a serious problem: once downloaded to a user's machine, the applet can now attempt to make a connection to any machine on the user's local area network, even if the LAN is protected by a firewall. Many LANs are set up so that local machines are trusted to access services that distant machines are not. As a trivial example, an Applet could open up a connection to the organization's private news server, fetch recent postings to an internal newsgroup, and transmit them back to a foreign host.
Unix users who are familiar with the Berkeley
rsh, rlogin and rcp commands
will see that this bug represents a risk to systems that
trust each other enough to allow commands to be executed remotely.
This bug also makes it possible for Applets to collect detailed
information on network topology and name services from behind
a firewall.
This security hole involves Java's trusting use of the Domain Name System (DNS) to confirm that it is allowed to contact a particular host. A malfeasant using his own DNS server can create a bogus DNS entry to fool the Java system into thinking that a script is allowed to talk to a host that it is not authorized to contact. This article describes the problem in more detail.
More information about Java and security can be found at URL:
http://java.sun.com/sfaq/
Unlike the Java hole, which can actively damage the user's machine, the JavaScript holes all involve infringements on the user's privacy. The following holes all exist in Netscape 2.01, and were discovered and publicized by John Robert LoVerso of the OSF Research Institute (mailto:loverso@osf.org:
http://www.osf.org/~loverso/javascript/Because of concerns for public safety, LoVerso has not generally released the details of all three holes. However it is unlikely that the same holes cannot be discovered by others.
It is expected that these bugs will be addressed in the next release of Netscape Navigator. However, until that time, you are strongly advised to turn JavaScript off (from the Network & Security Options dialog) except when retrieving URLs from well-known and trusted hosts. If you do choose to use JavaScript, be alert for pages that do unexpected things such as creating superfluous windows or prompting you to take unusual actions. These may be indications of a malevolent script at work.